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Fig. 2 



Buyer fills his shopping cart and proceeds to the merchant's 
checkout page. 



Buyer selects PIN Purchase as payment method and enters or 
selects his debit card number. 

I 

Merchant re-directs Buyer's browser to IAS and passes unique 

transaction id. 

I 

IAS displays a secure PIN pad screen, uses unique session key 

(SSL) technology. Buyer enters PIN using his mouse. The PIN is 
encrypted using the unique session key and passed to IAS. IAS 
passes encrypted PIN to HSM, which generates an encrypted ANSI 
PIN Block. 



IAS returns control of Buyer's browser to Merchant along with 
unique transaction id. 

I : 



Fig. 2, continued 

A 

Merchant creates payment request based on contents of the 
shopping cart and payment method. Merchant then sends 
payment request to IAS over a secure link. 



IAS determines payment type and formats payment authorization 
reauest. 



Payment authorization request is routed to ATM/POS System. 
ATM/POS System takes encrypted ANSI PIN block and routes it 
through second HSM to be decrypted and translated to the 
acquiring financial institution's encrypted PIN data. 



If transaction is on-us, then ATM/POS System validates the PIN 
and passes transaction amount to DDA System for authorization. 



If transaction is off-us, then authorization request is routed to 
network to be routed to Buyer's issuing financial institution. 



Authorization approval or denial is passed back to ATM/POS 
System, routed to the Internet Payments Server, and finally back 
to Merchant server. 



Fig. 3 



IAS receives control of user browser from merchant. Redirection 
process passes: merchant id, transaction id, return URL, and a 
merchant defined as its own entity and which does not contain the 
user's PIN. 
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IAS initiates a call to HSM to request a public key, PubK. 




r 


HSM returns PubK + Slot. 


1 5 


i . 


IAS passes JavaScript and PubK bad 


< to the user's browser. 
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User enters 4-12 digit PIN number and clicks on a submit button. 
Digits are shown as "*" on the popup frame. 
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DES key KD is generated at the user's browser. 


i 


Encrypt the entered PIN digits using KD(PIN). (314) 



(302) 



(304) 



(306) 



(308) 



(310) 



(312) 



(314) 



Fig. 3, continued 



Encrypt KD using PubK. 
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Post KD(PIN) + PubK(KD) to IAS. 
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IAS passes KD(PIN) + PubK(KD) + Slot to the HSM. 




r 



HSM converts KD(PIN) + PubK(KD) + Slot to MFK(KPE) + 
KPE(PIN), used to create a standard ANSI PIN block. HSM 
passes MFK(KPE) + KPE(PIN) back to the IAS. 



IAS stores MFK(KPE) + KPE(PIN) + Transaction Id + 
timestamp in the database. 
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